I think this needs some discussion, however no need to open an issue, we can also discuss here.

IMHO, the goal of this library shouldn't be to re-write all framework functions in pipe friendly way, and I agree with @dsyme when he states that we should instead embrace dot notation as it's a key feature of F# interoperability.

Having said that, we probably have some functions already in the String module which are or look like a re-write, but they also add the value of being context insensitive.

My feeling is that a DateTime module should bring an additional value, not just a whole rewrite, but if you feel that some functions should be made pipe friendly let's start by compiling a specific set of them, or even better some use cases where operating with the current set of functions become problematic.

PS: One function that I miss and would like to add is something like an efficient implementation of to/of Unix Time.

There is an RFC to make OO style entity access more palatable in F#.

There is an RFC to make OO style entity access more palatable in F#.

The point of the RFC is for cases like xs |> List.map _.Property

That is, even with the RFC the recommendation would always be to use x.Property rather than x |> _.Property unless there is specific reason to do so (which I think there almost never is). The notation x.Property is, frankly, better.

Indeed @dsyme. I used an overly broad categorisation of the RFC.

Thanks @dsyme for your clarification

unless there is specific reason to do so (which I think there almost never is).

note that the case being discussed here is mostly forward piping, I guess that's what you consider a valid reason.

note that the case being discussed here is mostly forward piping, I guess that's what you consider a valid reason.

Yes for

xs |> List.map _.Property

but I'd imagine almost never for

x |> _.Property

though I guess we'll see

x 
|> some-op
|> _.Property
|> some-op

Yes, looks like we're on the same page, I agree there's no reason to write x |> _.Property alone.

Closing this for now for the above reasons, we'll need to compile first a list of functions that have a specific justification.
For instance, the function ToLocalTime shouldn't be added as it depends on the context, we don't want to add functions like that in this module, on the contrary we'll like to make some functions non depending on the context as opposed to its .NET method version (like .ToString vs string).

Feel free to reply with a list of functions and we'll keep discussing and eventually re-open the PR.